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Traditional expert systems, such as diagnostic and trainirg 
systems, interact with users only through a keyboard and screen, 
and are usually symbolic in nature. Expert systems that require 
access to data bases, complex simulations and real-time 
instrumentation have both symbolic as well as algorithmic 
computing needs. These needs could both be met using a general 
purpose workstation running both symbolic and algorithmic code, 
or separate, specialized computers networked together. The 
latter approach was chosen to implement TEXSYS, the thermal 
expert system, developed by NASA Ames Research Center in 
conjunction with Johnson Space Center to demonstrate the ability 
of an expert system to autonomously control the thermal control 
system of the space station. TEXSYS has been implemented on a 
Symbolics workstation, and will be linked to a microVAX computer 
that will control a thermal test bed. This paper will explore 
the integration options, and present several possible solutions. 


Introduction 


As part of NASA's Systems Autonomy Demonstration Project 
(SADP) , a series of four demonstrations will be conducted to show 
the capability of increasingly complex expert systems applied to 
space station subsystems needs. The first of these 
demonstrations, the thermal expert system (TEXSYS), is being 
developed to show the use of artificial intelligence uevhnology 
in the operation and management of the space station thermal 
control system. This demonstration is a joint project of the 
Ames Research Center (ARC) and Johnson Space Center (JSC) under 
the direction of the Systems Autonomy Demonstration Project 
Office at ARC. TEXSYS [2] will be used to monitor, control, 
diagnose, and reconfigure a large space station prototype thermal 
test bed (FIB) ?t JSC. A small thermal test bed will be used at 
ARC during the i^velopment and testing of TEXSYS prior to 
integration with the large TTB system at JSC. 
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The thermal expert system being developed at ARC will 
consist of an expert system (TEXSYSJ and an intelligent human 
interface (HITEX) . TEXSYS contains the thermal domain knowledge 
provided by the Crew and Thermal division of JSC, and will be 
used for autonomous control, diagnosis and reconfiguration. 

HITEX is the "human interface" to the thermal expert system, 
providing explanation facilities and system status graphics. 

This latter system will be developed by the Human Factors 
Division at ARC to demonstrate an ergonomic interface to the TTB, 
such as would be required by the thermal engineer for use on the 
space station. The JSC test bed will be controlled by the TEXSYS 
Data Acquisition System (TDAS [6]). 

The thermal test bed at ARC is small version of the two- 
phase ammonia thermal bus prototype at JSC. The ARC TTB will be 
controlled by a conventional computer control system, and data 
collection and communications software will be developed by 
Lawrence Livermore National Laboratory. This paper describes the 
approach taken for integration of both the symbolic and 
algorithmic hardware and software used for the Ames thermal 
brassboard portion of this project. It is expected that this 
approach and its extensions will be compatible with and meet the 
requirements of the TEXSYS system when integrated into the JSC 
thermal test bed facility as described previously [6], 

Identifying Algorithmic vs. symbolic Processes 

The three major sections of this project are TEXSYS, HITEX 
and the TTB control functions. All three of these processes 
could conceivably be executed on one computer, but overall system 
performance would not be adequate. It was decided that each of 
these functions would be handled by separate computers integrated 
into one larger system. This approach allows the use of 
optimized hardware for each subsystem, and provides the 
capability for the eventual integration of cooperating expert 
systems, such as the 1990 SADP demonstration for cooperating 
expert systems involving the management of b^th the thermal and 
power systems . 

Separating algorithmic and symbolic processes to different 
computers has been shown previously to be very effective. The 
TQMSTUNE expert system developed at Lawrence Livermore National 
Laboratory [1,4 -5, 7 -8] runs on a Xerox LISP workstation, and 
communicates with a conventional minicomputer (DEC PDP-11/23) 
that operates the triple quadrupole mass spectrometer ( TQMS ) . 

The "tweaker" (a process of adjusting an instrumental parameter 
for maximum signal) was originally implemented, in LISP, on the 
Xerox workstation. When the tweaker was recoded in FORTRAN and 
ported to the control computer, the time required to tune the 
instrument (the goal of TQMSTUNE) was reduced by a factor of 6. 
This time difference reflected the symbolic or heuristic portions 
of the expert system's ability to perform better with high level 
information rather than large amounts of low level data. 



These concepts are being applied to the TEXSYS system. For 
example, the control and collection of data from the thermal test 
bed is an algorithmic process. These processes, as well as data 
reduction, storage and display are well understood and are being 
coded in standard algorithmic languages, such as FORTRAN and C. 

A conventional microVAX II algorithmic processor was chosen for 
this application. 

The heuristics of control, fault diagnosis, and 
reconfiguration are represented as symbolic processes. These 
processes comprise the heuristic part of TZXSYS and were designed 
using the Knowledge Engineering Environment, KEE (Intellicorp) 
and a NASA-developed model tool kit (MTK) for model-based 
reasoning on a Symbolics workstation [3]. The size, complexity, 
and symbolic nature of TEXSYS require that it remain on a 
specialized Symbolics LISP processor but must be able to freely 
access high level inform* on abstracted from all the data being 
acquired from the mieroVAx. 

The choice of algorithmic vs. symbolic workstation is less 
clear for HITEX, for it has simultaneous symbolic and algorithmic 
display needs. Therefore, a general purpose workstation (Sun 
Microsystems) able to handle both expert system development 
environments (i.e. KEE) and display process control graphics, 
will be utilized. 


Communications Requirements 

Each of the three systems briefly described above must be 
able to communicate with the others. Both the expert system 
TEXSYS and the human interface HITEX require current thermal test 
bed information, and both must be able to control the TTB. Each 
expert must be able to interact with the other, i.e. HITEX may be 
requested to explain a TEXSYS action, or HITEX (or the human 
operator) may need to instruct TEXSYS to change operational 
modes. Figure 1 shows the logical communications links required 
to implement this system and a few of the Ames TTB hardware 


Thermal Teat Bed 

Sensors (approx) 

60 te mpera t ure 
2 flow meter 
10 pressure 
2 liquid level 
1 pump RPM 


Output (approx) 

29 solenoid valve 

3 heaters 


Command/Data Messages 



Figure 1 







parameters that must be controlled. The same types of parameters 
must be controlled on the JSC prototype TTB with Similar data 
rates, but there are considerably more parameters on the JSC test 
bed. 


The control computer will be acquiring sensor input at a 
rate of once per second. The volume of data recorded make it 
impractical for TEXSYS and HITEX to evaluate the raw data for 
every decision. A second function of the control computer, 
therefore, is to extract meaningful information from the 
collected data. Examples of this data reduction include 
calculating the rate of change for a temperature sensor and 
checking all sensors for under or over limit conditions. With 
both the raw and processed data available, the expert system and 
the human interface can utilize whichever data is appropriate for 
a given rule or time constraint. A third function of the control 
computer is to moderate conflicting control commands from the two 
higher level systems. 

Both TEXSYS and HITEX will need to be able to control the 
TTB. Control functions include opening and closing valves, 
turning pumps on and off, ctumging set points, alarms and limits 
and initializing the entire system. Although it is possible to 
have both systems control the TTB at the same time, the control 
software will allow only one system to issue control commands. 
This Jillows the expert system, TEXGYS, to be in control, and know 
the state of the TTB. If the HITEX system needs to issue a 
command, it must request thcit TEXSYS issue that command. If for 
some reason TEXSYS is unable to control the test bed (i.e. the 
computer crashed) , the data acquisition computer will detect the 
lack of activity, and allow HITEX to control the TTB. 

Communications Hardware 

There are several possible hardware communications schemes, 
two of which are shown in Figure 2. In point-to-point topology, 
each process would have a dedicated link for every communication 
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channel. This is the simplest mechanism, but when the system 
grows beyond a few nodes, it becomes unmanageable. A bus 
oriented topology offers an easy growth path (for adding more 
systems) and often allows for logical point-to-point links. 
However, as a general purpose shared resource, a common bus may 
become a bottleneck and redu' i overall system performance. Based 
on these considerations, a combination of a common bus and a 
point-to-point link was adopted for the TEXSYS project. 

The choice of the communication scheme implemented is 
dependent on the required throughput of the communication 
channel. The throughput includes not only the bandwidth of the 
communications hardware, but also includes the software overhead 
associated with accessing that device. Each of the processors 
selected for this project are able to use ethemet as a 
communications bus. The protocol used to send packets over the 
ethemet will be either TCP/IP or DECNET, depending on the 
throughput of each package. 

TEXSYS may require large quantities of information from the 
data acquisition/control computer. A specialized point-to-point 
link between those two computers will be used. This "bus-link” 
(made by Flavors Technology, Inc.) allows the Symbolics computer 
direct access to a portion of the micro VAX memory. By copying 
the TTB parameters into a specified portion of the microVAX 
memory, TEXSYS is able to quickly retrieve any required datum. 
Control commands and communications with HITEX will use ethernet 
to provide consistent interface among all three systems. The use 
of both ethemet and the bus-link product give TEXSYS the best of 
both systems: a point-to-point link for accessing large 
quantities of data, and a common bus to provide an interface to 
other systems. 


Communications Software 

Expert systems running under the KEE shell are able to take 
advantage of a KEE feature, active values. When a rule (or LISP 
code) either gets or puts the value of a slot (e.g. reads or 
writes the value of a variable) , the active value method (e.g. 
subroutine or function) is invoked if it exists. This active 
value method may execute any code, and the the value it returns 
(for a GET. VALUE function of a slot) is used by the rule that 
requested the value. Both TEXSYS and HITEX use this mechanism to 
retrieve TTB parameters. For example, if a TEXSYS rule premise 
is based on the pressure before the condenser (eq. 1) , the rule 
interpreter retrieves the value of the transducer (eq. 2) and the 
active value methods tires (eq. 3) . This LISP code either looks 
up the value in the shared memory provided by the Bus-Link, or 
uses ethernet to request the value from the control computer. 

The active value method then returns a value, P, to the slot 
(eq. 4) , and the rule uses the returned value for its comparison 
(eq. 5) . Values may be set in the same way. 



if Pressure_before_condenser > limit than conclusion (1) 
GET. VALUE Pressure_bef ore_condenser (2) 
ATGET method (LISP code, returns P) (3) 
Pressure_before_condenser = P (4) 
if P > limit than conclusion (5) 


The use of active values allows for transparent use of the 
network to obtain the needed information, and can be used for all 
routine messages and data between the human interface and expert 
system and the control computer. This method was used for the 
TQMSTUNE system described earlier. It should be noted that the 
active value mechanism imposes a master/slave relationship upon 
the systems. 

Both the human interface and the expert system act as a 
communication master (requestor) , sending or receiving data as 
necessary to derive explanations of to test the rules. The 
control computer, however, must be able to quickly respond, at 
any time, to requests from one or more external systems. As a 
slave process (data server) , the control computer cannot send any 
data unless requested by the master process. In the event of an 
alarm condition (i.e. sensor out of limit), the control computer 
must wait until the expert system requests some data, and then 
may send a warning flag indicating a potential problem. The 
expert system may then request more information about the 
warning. Since the expert system is constantly requesting 
information and data from the control computer, the warning 
condition will be recognized in short order. This configuration 
assumes that the delay in the notification of a warning condition 
is minimal when compared to the overall response time required to 
service the alarm condition by the expert system. 

A second method of communicating between the expert system 
and the control computer is to have the expert system explicitly 
request information from the communications interface. This 
allows the expert system complete control over the knowledge 
base, and all information in it will be consistent. A separate 
process can receive data and alarms from the control computer, 
and the diagnostic portion of the system initiated if an alarm 
occurs . 


Communications Subsystem 

The active value mechanism works well for communications 
between the expert system and the control comp. iter, but for 
lengthy, information messages (i.e. TEXSYS explaining to HITEX 
why certain actions were taken) , a different approach should be 
taken. Two possible solutions are a direct logical connection 
between TEXSYS and HITEX over ethernet, or a microVAX buffered 
communications system between the human interface and the expert 
system. Both configurations are under consideration. 

Ethernet is used as the common communications bus; a 
communications interface, implemented on the microVAX, is used as 



the software communications bus. Figure 3 is a block diagram of 
this interface software. The communications interface acts as a 
central clearing agent for informational messages, warning 
messages and commands. Information messages, from whatever 
source, are saved until requested, while warning messages and 
commands are immediately sent to the target processes. In this 
way, only urgent messages (warnings and commands) interrupt the 
expert system, and routine informational messages are retrieved 
only when the expert system needs that information. 



Figure 3 


All systems interfaced to this message router have access to 
the TTB parameters and status (via the control system interface) . 
Daemon processes analyze the collected data ("other functions" in 
Figure 3) and issue warning messages when needed (i.e. if a 
pressure is rising too rapidly or is out o'* acceptable limits) . 

In theory, commands to control the TTB may be given by any 
connected process, but command conflicts would be a major 
problem, and would best be handled by the expert system. For this 
reason, it is expected that all commands will originate from 
TEXSYS, and HITEX will request TEXSYS to issue commands as 
necessary. 

The dedicated TEXSYS to control computer link is essentially 
a virtual memory device. This link is in addition to the 
ethernet link, and bypasses mu.'-h of the software overhead 
associated with the ethernet link. TEXSYS could operate without 
this link, but its use allows a significant decrease in TEXSYS 
access time to TTB parameters . 

Conclusions 

The division of processes among algorithmic and symbolic 
processors is usually straight forward. Accessing data bases or 
real-time instrumentation are algorithmic processes , while expert 
systems are generally symbolic in nature . To effectively 
integrate these these processes into a compor ce system requires 
an effective communications scheme. For sm .1 systems, point-to- 



point links are simple and sufficient; however, for large 
systems, bus topology and a message server are usually required. 
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